Main #2
Main #2
Conversation
[no changelog]
[no changelog]
[no changelog]
[no changelog]
Bumps [certifi](https://github.com/certifi/python-certifi) from 2023.7.22 to 2024.7.4. - [Commits](certifi/python-certifi@2023.07.22...2024.07.04) --- updated-dependencies: - dependency-name: certifi dependency-type: indirect ... Signed-off-by: dependabot[bot] <[email protected]>
[no changelog]
* Code improvement on printf
we need to cherry-pick two commits into the micropython submodule, and adapt one of the fixes
[no changelog]
jq --sort-keys -s '.[0] * .[1]' es.json es-ES_diff_tutorial.json > es.json.tmp && mv es.json.tmp es.json [no changelog]
[no changelog]
[no changelog]
Partially reverts 5fc3c6e. [no changelog]
* move most actual functionality to LayoutObjInner * subsume features of top-level Root and Child into LayoutObjInner (saving ~7 kB of flash because LayoutObjInner is not generic) * make use of GcBox to drop the top-level component
Previously, any C assertion or other case of __fatal_error would only show the RSOD, but not print to emulator output. That is (a) mildly annoying, and (b) would not work in the weird case in Rust unit tests where graphics are not available.
[no changelog]
[no changelog]
[no changelog]
complicated flows that _do not accomplish results_ do not belong into device_tests, so I moved them to click_tests and added stronger assert system
this includes D001 / D002, that probably doesn't matter
…github now that we don't really use gitlab anymore
to get rid of python 3.14 deprecation warnings
Python 3.11 changed IntEnum.__str__ to return the number instead of the enum value name. This breaks fixtures.json because pytest uses str(value) to generate the test identifier names, and in a lot of places our identifiers use the enum values. This override of `_idval_from_value` explicitly generates a name from the IntEnum instead of using the __str__ implementation.
|
I agree with the suggestion that we should branch off releases only and not pull Also:
|
Agree, having both main and master is confusing.
You mean like github fork feature? Not sure that it's a good idea because there are some limitations for forks like if the original repo got banned and removed from github all forks go down as well. Keeping a copy seems like a safer option. |
I don't think we should seriously consider the possibility of the official Trezor repo getting banned (and if it does happen, we can always create a copy post factum). What worries me here is that installing an unsigned custom firmware will already be quite scary for users. And the device will constantly warn them about it with this nice screen. So they'll want to make sure that our fork is as "public" as possible, which should increase the probability of it being reviewed by larger number of people. Us not having a proper github fork may look like we're trying to avoid extra publicity, which may be seen as suspicious. |
Update from trezor main to our master